feat(app): fall back to server MergeTree settings for block columns - #3530

A single persisted block column combined with the primary key does not
identify a row: _block_offset repeats across insert blocks, _block_number
across the rows of one block, and exporter-default tables key on a
second-precision TimestampTime. Since #3530 the block columns are also
detected from server-level merge_tree_settings, so any table without
explicit settings took the key-only path on servers that enable only
one of them and could open the wrong row.

Use the key-only lookup only when both block columns are persisted; a
lone block column is still appended to the full-row lookup as a
tiebreaker.

…kup (#3566)

## Summary

Clicking a search result could open the wrong row's details when the table persists only one of `_block_number` / `_block_offset`.

- Since #3364 the side panel used a key-only lookup (primary key + partition + whichever block column exists) when at least one block column was persisted. One block column is not unique: `_block_offset` repeats across insert blocks, `_block_number` across the rows of one block, and the primary key often doesn't break the tie (the OTel exporter default keys on the second-precision `TimestampTime`).
- Since #3530 the block columns are also detected from server-level `merge_tree_settings`, so on servers that enable only one of them, every table without explicit settings takes this path.
- The key-only lookup now requires both block columns. A lone block column is still appended to the full-row lookup as a tiebreaker.
- Tables that persist only one block column return to the full-row lookup and lose the #3364 speed-up. A `_part` + `_part_offset` lookup is the follow-up to restore it.

### How to reproduce

**Starting point:** `yarn dev`. Set the server default on the dev ClickHouse and restart it:

```sh
docker exec <ch-server> sh -c 'echo "<clickhouse><merge_tree><enable_block_offset_column>1</enable_block_offset_column></merge_tree></clickhouse>" > /etc/clickhouse-server/config.d/block_offset.xml'
docker restart <ch-server>
```

Create an exporter-shaped table and insert three rows as separate inserts, two in the same second:

```sql
CREATE TABLE default.repro_logs (
  Timestamp DateTime64(9), TimestampTime DateTime DEFAULT toDateTime(Timestamp),
  ServiceName LowCardinality(String), SeverityText LowCardinality(String), Body String,
  LogAttributes Map(LowCardinality(String), String)
) ENGINE = MergeTree PARTITION BY toDate(TimestampTime)
PRIMARY KEY (ServiceName, TimestampTime) ORDER BY (ServiceName, TimestampTime, Timestamp);

INSERT INTO default.repro_logs (Timestamp, ServiceName, SeverityText, Body) VALUES ('2026-11-05 09:00:39.845', 'saruman', 'INFO', 'Response x_span_id=ESLMARS7L7');
INSERT INTO default.repro_logs (Timestamp, ServiceName, SeverityText, Body) VALUES ('2026-11-05 09:00:39.100', 'saruman', 'INFO', 'Request x_span_id=ESOPOZ7FCV');
INSERT INTO default.repro_logs (Timestamp, ServiceName, SeverityText, Body) VALUES ('2026-11-05 09:00:36.909', 'saruman', 'INFO', 'Request x_span_id=ESLMARS7L7');
```

Add a log source for `default.repro_logs` (timestamp column `TimestampTime`), then search it for `"ESLMARS7L7"` over a range covering 2026-11-05 09:00 UTC.

**On `main`:**

1. Click the `Response x_span_id=ESLMARS7L7` row a few times.
2. The side panel shows `Request x_span_id=ESOPOZ7FCV` about half the time. The query in `system.query_log` is `WHERE ServiceName='saruman' AND TimestampTime=... AND toDate(TimestampTime)=... AND _block_offset='0' LIMIT 1`.

**On this branch:**

1. Click the same row. The panel always shows `Response x_span_id=ESLMARS7L7`; the query also filters on `Timestamp`, `SeverityText` and `Body`.

### How to test on Vercel preview

N/A — needs a ClickHouse server default; the demo server's user cannot read `system.merge_tree_settings`.

### References

- Related PRs: #3530, #3364, #2320, #2071

## Summary

On ClickHouse Cloud, read MergeTree settings from `system.shared_merge_tree_settings`, falling back to `system.merge_tree_settings` for each setting, when detecting persisted `_block_number` and `_block_offset` columns.

- `Metadata.getMergeTreeSettings` also reads `system.shared_merge_tree_settings` on Cloud (detected with `isClickHouseCloud`). Where both tables set a key, the shared value wins
- Outside Cloud it still reads only `system.merge_tree_settings`, since OSS servers don't have the shared table
- If the shared read fails on Cloud, it returns `undefined` (not cached), so the next call retries
- Unit tests for the non-Cloud path, the Cloud per-key preference, and the Cloud failure case

The code is identical to the EE change, so the forward-port should merge without conflicts.

### How to reproduce

**Starting point:** a ClickHouse Cloud service where block columns are enabled in the shared settings but not in `system.merge_tree_settings`. Check with:

```sql
SELECT 'merge_tree' AS t, name, value FROM system.merge_tree_settings WHERE name LIKE 'enable_block_%'
UNION ALL
SELECT 'shared', name, value FROM system.shared_merge_tree_settings WHERE name LIKE 'enable_block_%'
```

Add a log table on that service as a source, with no block-column settings in its `SETTINGS` clause, and ingest some rows.

**On `main`:**

1. Open the source in search and click a row.
2. In the ClickHouse query log, the row lookup doesn't use `_block_number` / `_block_offset` and falls back to matching the full row.

**On this branch:**

1. Repeat the steps above.
2. The row lookup now selects and filters on `_block_number` and `_block_offset`.

### How to test on Vercel preview

N/A — non-UI change.

### References

- Linear Issue: O11Y-29693
- Related PRs: backport of DeploySentinel/hyperdx-ee#3925, follows #3530